home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0147.txt < prev   
Encoding:
Text File  |  1993-07-02  |  3.8 KB  |  79 lines
  1.  
  2. On Sat, 3 Jul 1993, John Gardiner Myers wrote:
  3.  
  4. > If the advice to clients is reasonably interpreted as "ignore the
  5. > /SEEN flag for bboards and handle the per-user state yourself", then I
  6. > fear clients will store this information in the simplest and most
  7. > logical place (the local disk) and be done with it.  
  8.  
  9. Again, in many cases there won't be any per-user /SEEN flags stored on the
  10. archive server.  Whether or not client-writers choose the easy way out and
  11. store state locally depends largely on how easy we make it to access
  12. remote state files.  But I'll also mention a scenario below where having
  13. the state stored locally on the client is the *right* --indeed, only--
  14. thing to do. 
  15.  
  16. > Any distributed mechanism available to the client for handling this
  17. > information is at least equally available to the server.  
  18.  
  19. In principle, Yes.  In practice, Not necessarily.  I see a significant
  20. difference in operational cost when a (non-Kerberos) archive server
  21. suddenly needs to traffic in user-specific data. 
  22.  
  23. > As there are
  24. > usually fewer varieties of servers than clients, and as servers
  25. > usually don't run on low-resource machines, I believe it is much
  26. > simpler to get all servers to handle this correctly than to get all
  27. > clients to do so.
  28.  
  29. We have to solve the same problem for addressbooks and existing newsrc
  30. files, so I don't believe there is much increase in complexity or resource
  31. requirements for the client.  Moreover, as time goes on, shared server
  32. resources will become much more scarce than dedicated client resources. 
  33. Besides, the which-Unix-flavor server wars will go on forever, but in a 
  34. couple of years all clients will be running Win NT, won't they?  :) :)
  35.  
  36. Having the per-user state info manipulated on the server *requires* that
  37. the server have some cognizance of "user".  Within a Kerberos realm, this
  38. may not be a big problem, but in many other situations it will make the
  39. difference between whether or not the per-user services are available at
  40. all. 
  41.  
  42. Consider a small K12 school that may be running their own mail server, but
  43. is relying on another site for access to news and public archive data. If
  44. per-user state data can *only* be manipulated on the server, a teacher
  45. who's entire data world lives on their PC's hard disk is powerless to take
  46. advantage of these per-user services.  (I'm assuming a realistic view of
  47. how easy it is to get guest accounts set up at some other site as K12
  48. demand scales!) In contrast, if the per-user data *may* be manipulated by
  49. the client, then we can accommodate sites where central *support*
  50. resources are slim-to-none as well as sites with relatively rich computing
  51. infrastructures (both systems & staff).  NNTP is clearly a successful
  52. precedent for this model. 
  53.  
  54. I also want to see IMAPd code surface in the bazillion anonymous ftp
  55. servers around the world and suddenly have their mail archives available
  56. via IMAP.  These systems don't know about specific users in general, and
  57. 99.99% will never know about me in particular.  But I still want to be
  58. able to keep track of what messages I've seen/pseudo-deleted/answerd/etc. 
  59.  
  60. IF the IMAPd is the only one allowed to manipulate per user state info, I 
  61. now have several additional dependencies when compared to client-side state
  62. manipulation:
  63.   -My MUA must know how to authenticate itself to an IMAPd in any realm or
  64.    location, even for *public* data access,
  65.   -The IMAPd must know how and where to get my per-user state,
  66.   -The IMAPd must be able to authenticate me and/or it to the state server,
  67.   -and There must be a "state" server ready and willing to accommodate that 
  68.    request.
  69.  
  70. Within a particular site, having the server do the per-user state
  71. processing may be perfectly reasonable, though I'm not yet convinced it is
  72. preferable.  I am convinced that it is the wrong answer for the broader
  73. context cited above. 
  74.  
  75. -teg
  76.  
  77.  
  78.  
  79.